home *** CD-ROM | disk | FTP | other *** search
Text File | 2000-08-07 | 48.5 KB | 1,008 lines |
- Network Working Group D. Mills
- Request for Comments: 2030 University of Delaware
- Obsoletes: 1769 October 1996
- Category: Informational
-
-
- Simple Network Time Protocol (SNTP) Version 4
- for IPv4, IPv6 and OSI
-
- Status of this Memo
-
- This memo provides information for the Internet community. This memo
- does not specify an Internet standard of any kind. Distribution of
- this memo is unlimited.
-
- Abstract
-
- This memorandum describes the Simple Network Time Protocol (SNTP)
- Version 4, which is an adaptation of the Network Time Protocol (NTP)
- used to synchronize computer clocks in the Internet. SNTP can be used
- when the ultimate performance of the full NTP implementation
- described in RFC-1305 is not needed or justified. When operating with
- current and previous NTP and SNTP versions, SNTP Version 4 involves
- no changes to the NTP specification or known implementations, but
- rather a clarification of certain design features of NTP which allow
- operation in a simple, stateless remote-procedure call (RPC) mode
- with accuracy and reliability expectations similar to the UDP/TIME
- protocol described in RFC-868.
-
- The only significant protocol change in SNTP Version 4 over previous
- versions of NTP and SNTP is a modified header interpretation to
- accommodate Internet Protocol Version 6 (IPv6) [DEE96] and OSI
- [COL94] addressing. However, SNTP Version 4 includes certain optional
- extensions to the basic Version 3 model, including an anycast mode
- and an authentication scheme designed specifically for multicast and
- anycast modes. While the anycast mode extension is described in this
- document, the authentication scheme extension will be described in
- another document to be published later. Until such time that a
- definitive specification is published, these extensions should be
- considered provisional.
-
- This memorandum obsoletes RFC-1769, which describes SNTP Version 3.
- Its purpose is to correct certain inconsistencies in the previous
- document and to clarify header formats and protocol operations for
- current NTP Version 3 (IPv4) and proposed NTP Version 4 (IPv6 and
- OSI), which are also used for SNTP. A working knowledge of the NTP
- Version 3 specification RFC-1305 is not required for an
- implementation of SNTP.
-
-
-
- Mills Informational [Page 1]
-
- RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
-
-
- 1. Introduction
-
- The Network Time Protocol (NTP) Version 3 specified in RFC-1305
- [MIL92] is widely used to synchronize computer clocks in the global
- Internet. It provides comprehensive mechanisms to access national
- time and frequency dissemination services, organize the time-
- synchronization subnet and adjust the local clock in each
- participating subnet peer. In most places of the Internet of today,
- NTP provides accuracies of 1-50 ms, depending on the characteristics
- of the synchronization source and network paths.
-
- RFC-1305 specifies the NTP Version 3 protocol machine in terms of
- events, states, transition functions and actions and, in addition,
- engineered algorithms to improve the timekeeping quality and mitigate
- among several synchronization sources, some of which may be faulty.
- To achieve accuracies in the low milliseconds over paths spanning
- major portions of the Internet of today, these intricate algorithms,
- or their functional equivalents, are necessary. However, in many
- cases accuracies in the order of significant fractions of a second
- are acceptable. In such cases, simpler protocols such as the Time
- Protocol [POS83], have been used for this purpose. These protocols
- usually involve an RPC exchange where the client requests the time of
- day and the server returns it in seconds past some known reference
- epoch.
-
- NTP is designed for use by clients and servers with a wide range of
- capabilities and over a wide range of network delays and jitter
- characteristics. Most users of the Internet NTP synchronization
- subnet of today use a software package including the full suite of
- NTP options and algorithms, which are relatively complex, real-time
- applications (see http://www.eecis.udel.edu/~ntp). While the software
- has been ported to a wide variety of hardware platforms ranging from
- personal computers to supercomputers, its sheer size and complexity
- is not appropriate for many applications. Accordingly, it is useful
- to explore alternative access strategies using simpler software
- appropriate for less stringent accuracy expectations.
-
- This document describes the Simple Network Time Protocol (SNTP)
- Version 4, which is a simplified access strategy for servers and
- clients using NTP Version 3 as now specified and deployed in the
- Internet, as well as NTP Version 4 now under development. The access
- paradigm is identical to the UDP/TIME Protocol and, in fact, it
- should be easily possible to adapt a UDP/TIME client implementation,
- say for a personal computer, to operate using SNTP. Moreover, SNTP is
- also designed to operate in a dedicated server configuration
- including an integrated radio clock. With careful design and control
- of the various latencies in the system, which is practical in a
- dedicated design, it is possible to deliver time accurate to the
-
-
-
- Mills Informational [Page 2]
-
- RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
-
-
- order of microseconds.
-
- SNTP Version 4 is designed to coexist with existing NTP and SNTP
- Version 3 clients and servers, as well as proposed Version 4 clients
- and servers. When operating with current and previous versions of NTP
- and SNTP, SNTP Version 4 requires no changes to the protocol or
- implementations now running or likely to be implemented specifically
- for NTP ir SNTP Version 4. To a NTP or SNTP server, NTP and SNTP
- clients are undistinguishable; to a NTP or SNTP client, NTP and SNTP
- servers are undistinguishable. Like NTP servers operating in non-
- symmetric modes, SNTP servers are stateless and can support large
- numbers of clients; however, unlike most NTP clients, SNTP clients
- normally operate with only a single server. NTP and SNTP Version 3
- servers can operate in unicast and multicast modes. In addition, SNTP
- Version 4 clients and servers can implement extensions to operate in
- anycast mode.
-
- It is strongly recommended that SNTP be used only at the extremities
- of the synchronization subnet. SNTP clients should operate only at
- the leaves (highest stratum) of the subnet and in configurations
- where no NTP or SNTP client is dependent on another SNTP client for
- synchronization. SNTP servers should operate only at the root
- (stratum 1) of the subnet and then only in configurations where no
- other source of synchronization other than a reliable radio or modem
- time service is available. The full degree of reliability ordinarily
- expected of primary servers is possible only using the redundant
- sources, diverse subnet paths and crafted algorithms of a full NTP
- implementation. This extends to the primary source of synchronization
- itself in the form of multiple radio or modem sources and backup
- paths to other primary servers should all sources fail or the
- majority deliver incorrect time. Therefore, the use of SNTP rather
- than NTP in primary servers should be carefully considered.
-
- An important provision in this document is the reinterpretation of
- certain NTP Versino 4 header fields which provide for IPv6 and OSI
- addressing and optional anycast extensions designed specifically for
- multicast service. These additions are in conjunction with the
- proposed NTP Version 4 specification, which will appear as a separate
- document. The only difference between the current NTP Version 3 and
- proposed NTP Version 4 header formats is the interpretation of the
- four-octet Reference Identifier field, which is used primarily to
- detect and avoid synchronization loops. In Version 3 and Version 4
- primary (stratum-1) servers, this field contains the four-character
- ASCII reference identifier defined later in this document. In Version
- 3 secondary servers and clients, it contains the 32-bit IPv4 address
- of the synchronization source. In Version 4 secondary servers and
- clients, it contains the low order 32 bits of the last transmit
- timestamp received from the synchronization source.
-
-
-
- Mills Informational [Page 3]
-
- RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
-
-
- In the case of OSI, the Connectionless Transport Service (CLTS) is
- used [ISO86]. Each SNTP packet is transmitted as tht TS-Userdata
- parameter of a T-UNITDATA Request primitive. Alternately, the header
- can be encapsulated in a TPDU which itself is transported using UDP
- [DOB91]. It is not advised that NTP be operated at the upper layers
- of the OSI stack, such as might be inferred from [FUR94], as this
- could seriously degrade accuracy. With the header formats defined in
- this document, it is in principle possible to interwork between
- servers and clients of one protocol family and another, although the
- practical difficulties may make this inadvisable.
-
- In the following, indented paragraphs such as this one contain
- information not required by the formal protocol specification, but
- considered good practice in protocol implementations.
-
- 2. Operating Modes and Addressing
-
- SNTP Version 4 can operate in either unicast (point to point),
- multicast (point to multipoint) or anycast (multipoint to point)
- modes. A unicast client sends a request to a designated server at its
- unicast address and expects a reply from which it can determine the
- time and, optionally, the roundtrip delay and local clock offset
- relative to the server. A multicast server periodically sends a
- unsolicited message to a designated IPv4 or IPv6 local broadcast
- address or multicast group address and ordinarily expects no requests
- from clients. A multicast client listens on this address and
- ordinarily sends no requests. An anycast client sends a request to a
- designated IPv4 or IPv6 local broadcast address or multicast group
- address. One or more anycast servers reply with their individual
- unicast addresses. The client binds to the first one received, then
- continues operation in unicast mode.
-
- Multicast servers should respond to client unicast requests, as
- well as send unsolicited multicast messages. Multicast clients may
- send unicast requests in order to determine the network
- propagation delay between the server and client and then continue
- operation in multicast mode.
-
- In unicast mode, the client and server end-system addresses are
- assigned following the usual IPv4, IPv6 or OSI conventions. In
- multicast mode, the server uses a designated local broadcast address
- or multicast group address. An IP local broadcast address has scope
- limited to a single IP subnet, since routers do not propagate IP
- broadcast datagrams. On the other hand, an IP multicast group address
- has scope extending to potentially the entire Internet. The scoping,
- routing and group membership procedures are determined by
- considerations beyond the scope of this document. For IPv4, the IANA
- has assigned the multicast group address 224.0.1.1 for NTP, which is
-
-
-
- Mills Informational [Page 4]
-
- RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
-
-
- used both by multicast servers and anycast clients. NTP multicast
- addresses for IPv6 and OSI have yet to be determined.
-
- Multicast clients listen on the designated local broadcast address or
- multicast group address. In the case of local broadcast addresses, no
- further provisions are necessary. In the case of IP multicast
- addresses, the multicast client and anycast server must implement the
- Internet Group Management Protocol (IGMP) [DEE89], in order that the
- local router joins the multicast group and relays messages to the
- IPv4 or IPv6 multicast group addresses assigned by the IANA. Other
- than the IP addressing conventions and IGMP, there is no difference
- in server or client operations with either the local broadcast
- address or multicast group address.
-
- It is important to adjust the time-to-live (TTL) field in the IP
- header of multicast messages to a reasonable value, in order to
- limit the network resources used by this (and any other) multicast
- service. Only multicast clients in scope will receive multicast
- server messages. Only cooperating anycast servers in scope will
- reply to a client request. The engineering principles which
- determine the proper value to be used are beyond the scope of this
- document.
-
- Anycast mode is designed for use with a set of cooperating servers
- whose addresses are not known beforehand by the client. An anycast
- client sends a request to the designated local broadcast or multicast
- group address as described below. For this purpose, the NTP multicast
- group address assigned by the IANA is used. One or more anycast
- servers listen on the designated local broadcast address or multicast
- group address. Each anycast server, upon receiving a request, sends a
- unicast reply message to the originating client. The client then
- binds to the first such message received and continues operation in
- unicast mode. Subsequent replies from other anycast servers are
- ignored.
-
- In the case of SNTP as specified herein, there is a very real
- vulnerability that SNTP multicast clients can be disrupted by
- misbehaving or hostile SNTP or NTP multicast servers elsewhere in
- the Internet, since at present all such servers use the same IPv4
- multicast group address assigned by the IANA. Where necessary,
- access control based on the server source address can be used to
- select only the designated server known to and trusted by the
- client. The use of cryptographic authentication scheme defined in
- RFC-1305 is optional; however, implementors should be advised that
- extensions to this scheme are planned specifically for NTP
- multicast and anycast modes.
-
-
-
-
-
- Mills Informational [Page 5]
-
- RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
-
-
- While not integral to the SNTP specification, it is intended that
- IP broadcast addresses will be used primarily in IP subnets and
- LAN segments including a fully functional NTP server with a number
- of dependent SNTP multicast clients on the same subnet, while IP
- multicast group addresses will be used only in cases where the TTL
- is engineered specifically for each service domain.
-
- In NTP Version 3, the reference identifier was often used to
- walk-back the synchronization subnet to the root (primary server)
- for management purposes. In NTP Version 4, this feature is not
- available, since the addresses are longer than 32 bits. However,
- the intent in the protocol design was to provide a way to detect
- and avoid loops. A peer could determine that a loop was possible
- by comparing the contents of this field with the IPv4 destination
- address in the same packet. A NTP Version 4 server can accomplish
- the same thing by comparing the contents of this field with the
- low order 32 bits of the originate timestamp in the same packet.
- There is a small possibility of false alarm in this scheme, but
- the false alarm rate can be minimized by randomizing the low order
- unused bits of the transmit timestamp.
-
- 3. NTP Timestamp Format
-
- SNTP uses the standard NTP timestamp format described in RFC-1305 and
- previous versions of that document. In conformance with standard
- Internet practice, NTP data are specified as integer or fixed-point
- quantities, with bits numbered in big-endian fashion from 0 starting
- at the left, or high-order, position. Unless specified otherwise, all
- quantities are unsigned and may occupy the full field width with an
- implied 0 preceding bit 0.
-
- Since NTP timestamps are cherished data and, in fact, represent the
- main product of the protocol, a special timestamp format has been
- established. NTP timestamps are represented as a 64-bit unsigned
- fixed-point number, in seconds relative to 0h on 1 January 1900. The
- integer part is in the first 32 bits and the fraction part in the
- last 32 bits. In the fraction part, the non-significant low order can
- be set to 0.
-
- It is advisable to fill the non-significant low order bits of the
- timestamp with a random, unbiased bitstring, both to avoid
- systematic roundoff errors and as a means of loop detection and
- replay detection (see below). One way of doing this is to generate
- a random bitstring in a 64-bit word, then perform an arithmetic
- right shift a number of bits equal to the number of significant
- bits of the timestamp, then add the result to the original
- timestamp.
-
-
-
-
- Mills Informational [Page 6]
-
- RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
-
-
- This format allows convenient multiple-precision arithmetic and
- conversion to UDP/TIME representation (seconds), but does complicate
- the conversion to ICMP Timestamp message representation, which is in
- milliseconds. The maximum number that can be represented is
- 4,294,967,295 seconds with a precision of about 200 picoseconds,
- which should be adequate for even the most exotic requirements.
-
- 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Seconds |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Seconds Fraction (0-padded) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Note that, since some time in 1968 (second 2,147,483,648) the most
- significant bit (bit 0 of the integer part) has been set and that the
- 64-bit field will overflow some time in 2036 (second 4,294,967,296).
- Should NTP or SNTP be in use in 2036, some external means will be
- necessary to qualify time relative to 1900 and time relative to 2036
- (and other multiples of 136 years). There will exist a 200-picosecond
- interval, henceforth ignored, every 136 years when the 64-bit field
- will be 0, which by convention is interpreted as an invalid or
- unavailable timestamp.
-
- As the NTP timestamp format has been in use for the last 17 years,
- it remains a possibility that it will be in use 40 years from now
- when the seconds field overflows. As it is probably inappropriate
- to archive NTP timestamps before bit 0 was set in 1968, a
- convenient way to extend the useful life of NTP timestamps is the
- following convention: If bit 0 is set, the UTC time is in the
- range 1968-2036 and UTC time is reckoned from 0h 0m 0s UTC on 1
- January 1900. If bit 0 is not set, the time is in the range 2036-
- 2104 and UTC time is reckoned from 6h 28m 16s UTC on 7 February
- 2036. Note that when calculating the correspondence, 2000 is not a
- leap year. Note also that leap seconds are not counted in the
- reckoning.
-
- 4. NTP Message Format
-
- Both NTP and SNTP are clients of the User Datagram Protocol (UDP)
- [POS80], which itself is a client of the Internet Protocol (IP)
- [DAR81]. The structure of the IP and UDP headers is described in the
- cited specification documents and will not be detailed further here.
- The UDP port number assigned to NTP is 123, which should be used in
- both the Source Port and Destination Port fields in the UDP header.
- The remaining UDP header fields should be set as described in the
- specification.
-
-
-
- Mills Informational [Page 7]
-
- RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
-
-
- Below is a description of the NTP/SNTP Version 4 message format,
- which follows the IP and UDP headers. This format is identical to
- that described in RFC-1305, with the exception of the contents of the
- reference identifier field. The header fields are defined as follows:
-
- 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |LI | VN |Mode | Stratum | Poll | Precision |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Root Delay |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Root Dispersion |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Reference Identifier |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- | Reference Timestamp (64) |
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- | Originate Timestamp (64) |
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- | Receive Timestamp (64) |
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- | Transmit Timestamp (64) |
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Key Identifier (optional) (32) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- | |
- | Message Digest (optional) (128) |
- | |
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- As described in the next section, in SNTP most of these fields are
- initialized with pre-specified data. For completeness, the function
- of each field is briefly summarized below.
-
-
-
-
-
-
-
- Mills Informational [Page 8]
-
- RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
-
-
- Leap Indicator (LI): This is a two-bit code warning of an impending
- leap second to be inserted/deleted in the last minute of the current
- day, with bit 0 and bit 1, respectively, coded as follows:
-
- LI Value Meaning
- -------------------------------------------------------
- 00 0 no warning
- 01 1 last minute has 61 seconds
- 10 2 last minute has 59 seconds)
- 11 3 alarm condition (clock not synchronized)
-
- Version Number (VN): This is a three-bit integer indicating the
- NTP/SNTP version number. The version number is 3 for Version 3 (IPv4
- only) and 4 for Version 4 (IPv4, IPv6 and OSI). If necessary to
- distinguish between IPv4, IPv6 and OSI, the encapsulating context
- must be inspected.
-
- Mode: This is a three-bit integer indicating the mode, with values
- defined as follows:
-
- Mode Meaning
- ------------------------------------
- 0 reserved
- 1 symmetric active
- 2 symmetric passive
- 3 client
- 4 server
- 5 broadcast
- 6 reserved for NTP control message
- 7 reserved for private use
-
- In unicast and anycast modes, the client sets this field to 3
- (client) in the request and the server sets it to 4 (server) in the
- reply. In multicast mode, the server sets this field to 5
- (broadcast).
-
- Stratum: This is a eight-bit unsigned integer indicating the stratum
- level of the local clock, with values defined as follows:
-
- Stratum Meaning
- ----------------------------------------------
- 0 unspecified or unavailable
- 1 primary reference (e.g., radio clock)
- 2-15 secondary reference (via NTP or SNTP)
- 16-255 reserved
-
-
-
-
-
-
- Mills Informational [Page 9]
-
- RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
-
-
- Poll Interval: This is an eight-bit signed integer indicating the
- maximum interval between successive messages, in seconds to the
- nearest power of two. The values that can appear in this field
- presently range from 4 (16 s) to 14 (16284 s); however, most
- applications use only the sub-range 6 (64 s) to 10 (1024 s).
-
- Precision: This is an eight-bit signed integer indicating the
- precision of the local clock, in seconds to the nearest power of two.
- The values that normally appear in this field range from -6 for
- mains-frequency clocks to -20 for microsecond clocks found in some
- workstations.
-
- Root Delay: This is a 32-bit signed fixed-point number indicating the
- total roundtrip delay to the primary reference source, in seconds
- with fraction point between bits 15 and 16. Note that this variable
- can take on both positive and negative values, depending on the
- relative time and frequency offsets. The values that normally appear
- in this field range from negative values of a few milliseconds to
- positive values of several hundred milliseconds.
-
- Root Dispersion: This is a 32-bit unsigned fixed-point number
- indicating the nominal error relative to the primary reference
- source, in seconds with fraction point between bits 15 and 16. The
- values that normally appear in this field range from 0 to several
- hundred milliseconds.
-
- Reference Identifier: This is a 32-bit bitstring identifying the
- particular reference source. In the case of NTP Version 3 or Version
- 4 stratum-0 (unspecified) or stratum-1 (primary) servers, this is a
- four-character ASCII string, left justified and zero padded to 32
- bits. In NTP Version 3 secondary servers, this is the 32-bit IPv4
- address of the reference source. In NTP Version 4 secondary servers,
- this is the low order 32 bits of the latest transmit timestamp of the
- reference source. NTP primary (stratum 1) servers should set this
- field to a code identifying the external reference source according
- to the following list. If the external reference is one of those
- listed, the associated code should be used. Codes for sources not
- listed can be contrived as appropriate.
-
-
-
-
-
-
-
-
-
-
-
-
-
- Mills Informational [Page 10]
-
- RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
-
-
- Code External Reference Source
- ----------------------------------------------------------------
- LOCL uncalibrated local clock used as a primary reference for
- a subnet without external means of synchronization
- PPS atomic clock or other pulse-per-second source
- individually calibrated to national standards
- ACTS NIST dialup modem service
- USNO USNO modem service
- PTB PTB (Germany) modem service
- TDF Allouis (France) Radio 164 kHz
- DCF Mainflingen (Germany) Radio 77.5 kHz
- MSF Rugby (UK) Radio 60 kHz
- WWV Ft. Collins (US) Radio 2.5, 5, 10, 15, 20 MHz
- WWVB Boulder (US) Radio 60 kHz
- WWVH Kaui Hawaii (US) Radio 2.5, 5, 10, 15 MHz
- CHU Ottawa (Canada) Radio 3330, 7335, 14670 kHz
- LORC LORAN-C radionavigation system
- OMEG OMEGA radionavigation system
- GPS Global Positioning Service
- GOES Geostationary Orbit Environment Satellite
-
- Reference Timestamp: This is the time at which the local clock was
- last set or corrected, in 64-bit timestamp format.
-
- Originate Timestamp: This is the time at which the request departed
- the client for the server, in 64-bit timestamp format.
-
- Receive Timestamp: This is the time at which the request arrived at
- the server, in 64-bit timestamp format.
-
- Transmit Timestamp: This is the time at which the reply departed the
- server for the client, in 64-bit timestamp format.
-
- Authenticator (optional): When the NTP authentication scheme is
- implemented, the Key Identifier and Message Digest fields contain the
- message authentication code (MAC) information defined in Appendix C
- of RFC-1305.
-
- 5. SNTP Client Operations
-
- A SNTP client can operate in multicast mode, unicast mode or anycast
- mode. In multicast mode, the client sends no request and waits for a
- broadcast (mode 5) from a designated multicast server. In unicast
- mode, the client sends a request (mode 3) to a designated unicast
- server and expects a reply (mode 4) from that server. In anycast
- mode, the client sends a request (mode 3) to a designated local
- broadcast or multicast group address and expects a reply (mode 4)
- from one or more anycast servers. The client uses the first reply
-
-
-
- Mills Informational [Page 11]
-
- RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
-
-
- received to establish the particular server for subsequent unicast
- operations. Later replies from this server (duplicates) or any other
- server are ignored. Other than the selection of address in the
- request, the operations of anycast and unicast clients are identical.
- Requests are normally sent at intervals from 64 s to 1024 s,
- depending on the frequency tolerance of the client clock and the
- required accuracy.
-
- A unicast or anycast client initializes the NTP message header, sends
- the request to the server and strips the time of day from the
- Transmit Timestamp field of the reply. For this purpose, all of the
- NTP header fields shown above can be set to 0, except the first octet
- and (optional) Transmit Timestamp fields. In the first octet, the LI
- field is set to 0 (no warning) and the Mode field is set to 3
- (client). The VN field must agree with the version number of the
- NTP/SNTP server; however, Version 4 servers will also accept previous
- versions. Version 3 (RFC-1305) and Version 2 (RFC-1119) servers
- already accept all previous versions, including Version 1 (RFC-1059).
- Note that Version 0 (RFC-959) is no longer supported by any other
- version.
-
- Since there will probably continue to be NTP and SNTP servers of all
- four versions interoperating in the Internet, careful consideration
- should be given to the version used by SNTP Version 4 clients. It is
- recommended that clients use the latest version known to be supported
- by the selected server in the interest of the highest accuracy and
- reliability. SNTP Version 4 clients can interoperate with all
- previous version NTP and SNTP servers, since the header fields used
- by SNTP clients are unchanged. Version 4 servers are required to
- reply in the same version as the request, so the VN field of the
- request also specifies the version of the reply.
-
- While not necessary in a conforming client implementation, in unicast
- and anycast modes it highly recommended that the transmit timestamp
- in the request is set to the time of day according to the client
- clock in NTP timestamp format. This allows a simple calculation to
- determine the propagation delay between the server and client and to
- align the local clock generally within a few tens of milliseconds
- relative to the server. In addition, this provides a simple method to
- verify that the server reply is in fact a legitimate response to the
- specific client request and avoid replays. In multicast mode, the
- client has no information to calculate the propagation delay or
- determine the validity of the server, unless the NTP authentication
- scheme is used.
-
- To calculate the roundtrip delay d and local clock offset t relative
- to the server, the client sets the transmit timestamp in the request
- to the time of day according to the client clock in NTP timestamp
-
-
-
- Mills Informational [Page 12]
-
- RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
-
-
- format. The server copies this field to the originate timestamp in
- the reply and sets the receive timestamp and transmit timestamp to
- the time of day according to the server clock in NTP timestamp
- format.
-
- When the server reply is received, the client determines a
- Destination Timestamp variable as the time of arrival according to
- its clock in NTP timestamp format. The following table summarizes the
- four timestamps.
-
- Timestamp Name ID When Generated
- ------------------------------------------------------------
- Originate Timestamp T1 time request sent by client
- Receive Timestamp T2 time request received by server
- Transmit Timestamp T3 time reply sent by server
- Destination Timestamp T4 time reply received by client
-
- The roundtrip delay d and local clock offset t are defined as
-
- d = (T4 - T1) - (T2 - T3) t = ((T2 - T1) + (T3 - T4)) / 2.
-
- The following table summarizes the SNTP client operations in unicast,
- anycast and multicast modes. The recommended error checks are shown
- in the Reply and Multicast columns in the table. The message should
- be considered valid only if all the fields shown contain values in
- the respective ranges. Whether to believe the message if one or more
- of the fields marked "ignore" contain invalid values is at the
- discretion of the implementation.
-
- Field Name Unicast/Anycast Multicast
- Request Reply
- ----------------------------------------------------------
- LI 0 0-2 0-2
- VN 1-4 copied from 1-4
- request
- Mode 3 4 5
- Stratum 0 1-14 1-14
- Poll 0 ignore ignore
- Precision 0 ignore ignore
- Root Delay 0 ignore ignore
- Root Dispersion 0 ignore ignore
- Reference Identifier 0 ignore ignore
- Reference Timestamp 0 ignore ignore
- Originate Timestamp 0 (see text) ignore
- Receive Timestamp 0 (see text) ignore
- Transmit Timestamp (see text) nonzero nonzero
- Authenticator optional optional optional
-
-
-
-
- Mills Informational [Page 13]
-
- RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
-
-
- 6. SNTP Server Operations
-
- A SNTP Version 4 server operating with either a NTP or SNTP client of
- the same or previous versions retains no persistent state. Since a
- SNTP server ordinarily does not implement the full set of NTP
- algorithms intended to support redundant peers and diverse network
- paths, a SNTP server should be operated only in conjunction with a
- source of external synchronization, such as a reliable radio clock or
- telephone modem. In this case it always operates as a primary
- (stratum 1) server.
-
- A SNTP server can operate in unicast mode, anycast mode, multicast
- mode or any combination of these modes. In unicast and anycast modes,
- the server receives a request (mode 3), modifies certain fields in
- the NTP header, and sends a reply (mode 4), possibly using the same
- message buffer as the request. In anycast mode, the server listens on
- the designated local broadcast or multicast group address assigned by
- the IANA, but uses its own unicast address in the source address
- field of the reply. Other than the selection of address in the reply,
- the operations of anycast and unicast servers are identical.
- Multicast messages are normally sent at poll intervals from 64 s to
- 1024 s, depending on the expected frequency tolerance of the client
- clocks and the required accuracy.
-
- In unicast and anycast modes, the VN and Poll fields of the request
- are copied intact to the reply. If the Mode field of the request is 3
- (client), it is set to 4 (server) in the reply; otherwise, this field
- is set to 2 (symmetric passive) in order to conform to the NTP
- specification. This allows clients configured in symmetric active
- (mode 1) to interoperate successfully, even if configured in possibly
- suboptimal ways. In multicast (unsolicited) mode, the VN field is set
- to 4, the Mode field is set to 5 (broadcast), and the Poll field set
- to the nearest integer base-2 logarithm of the poll interval.
-
- Note that it is highly desirable that, if a server supports
- multicast mode, it also supports unicast mode. This is so a
- potential multicast client can calculate the propagation delay
- using a client/server exchange prior to regular operation using
- only multicast mode. If the server supports anycast mode, then it
- must support unicast mode. There does not seem to be a great
- advantage to operate both multicast and anycast modes at the same
- time, although the protocol specification does not forbid it.
-
- In unicast and anycast modes, the server may or may not respond if
- not synchronized to a correctly operating radio clock, but the
- preferred option is to respond, since this allows reachability to be
- determined regardless of synchronization state. In multicast mode,
- the server sends broadcasts only if synchronized to a correctly
-
-
-
- Mills Informational [Page 14]
-
- RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
-
-
- operating reference clock.
-
- The remaining fields of the NTP header are set in the following way.
- Assuming the server is synchronized to a radio clock or other primary
- reference source and operating correctly, the LI field is set to 0
- and the Stratum field is set to 1 (primary server); if not, the
- Stratum field is set to 0 and the LI field is set to 3. The Precision
- field is set to reflect the maximum reading error of the local clock.
- For all practical cases it is computed as the negative of the number
- of significant bits to the right of the decimal point in the NTP
- timestamp format. The Root Delay and Root Dispersion fields are set
- to 0 for a primary server; optionally, the Root Dispersion field can
- be set to a value corresponding to the maximum expected error of the
- radio clock itself. The Reference Identifier is set to designate the
- primary reference source, as indicated in the table of Section 5 of
- this document.
-
- The timestamp fields are set as follows. If the server is
- unsynchronized or first coming up, all timestamp fields are set to
- zero. If synchronized, the Reference Timestamp is set to the time the
- last update was received from the radio clock or modem. In unicast
- and anycast modes, the Receive Timestamp and Transmit Timestamp
- fields are set to the time of day when the message is sent and the
- Originate Timestamp field is copied unchanged from the Transmit
- Timestamp field of the request. It is important that this field be
- copied intact, as a NTP client uses it to avoid replays. In multicast
- mode, the Originate Timestamp and Receive Timestamp fields are set to
- 0 and the Transmit Timestamp field is set to the time of day when the
- message is sent. The following table summarizes these actions.
-
- Field Name Unicast/Anycast Multicast
- Request Reply
- ----------------------------------------------------------
- LI ignore 0 or 3 0 or 3
- VN 1-4 copied from 4
- request
- Mode 3 2 or 4 5
- Stratum ignore 1 1
- Poll ignore copied from log2 poll
- request interval
- Precision ignore -log2 server -log2 server
- significant significant
- bits bits
- Root Delay ignore 0 0
- Root Dispersion ignore 0 0
- Reference Identifier ignore source ident source ident
- Reference Timestamp ignore time of last time of last
- radio update radio update
-
-
-
- Mills Informational [Page 15]
-
- RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
-
-
- Originate Timestamp ignore copied from 0
- transmit
- timestamp
- Receive Timestamp ignore time of day 0
- Transmit Timestamp (see text) time of day time of day
- Authenticator optional optional optional
-
- There is some latitude on the part of most clients to forgive invalid
- timestamps, such as might occur when first coming up or during
- periods when the primary reference source is inoperative. The most
- important indicator of an unhealthy server is the LI field, in which
- a value of 3 indicates an unsynchronized condition. When this value
- is displayed, clients should discard the server message, regardless
- of the contents of other fields.
-
- 7. Configuration and Management
-
- Initial setup for SNTP servers and clients can be done using a
- configuration file if a file system is available, or a serial port if
- not. It is intended that in-service management of NTP and SNTP
- Version 4 servers and clients be performed using SNMP and a suitable
- MIB to be published later. Ordinarily, SNTP servers and clients are
- expected to operate with little or no site-specific configuration,
- other than specifying the IP address and subnet mask or OSI NSAP
- address.
-
- Unicast clients must be provided with the designated server name or
- address. If a server name is used, the address of one of more DNS
- servers must be provided. Multicast servers and anycast clients must
- be provided with the TTL and local broadcast or multicast group
- address. Anycast servers and multicast clients may be configured with
- a list of address-mask pairs for access control, so that only those
- clients or servers known to be trusted will be used. These servers
- and clients must implement the IGMP protocol and be provided with the
- local broadcast or multicast group address as well. The configuration
- data for cryptographic authentication is beyond the scope of this
- document.
-
- There are several scenarios which provide automatic server discovery
- and selection for SNTP clients with no pre-specified configuration,
- other than the IP address and subnet mask or OSI NSAP address. For a
- IP subnet or LAN segment including a fully functional NTP server, the
- clients can be configured for multicast mode using the local
- broadcast address. The same approach can be used with other servers
- using the multicast group address. In both cases, provision of an
- access control list is a good way to insure only trusted sources can
- be used to set the local clock.
-
-
-
-
- Mills Informational [Page 16]
-
- RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
-
-
- In another scenario suitable for an extended network with significant
- network propagation delays, clients can be configured for anycast
- mode, both upon initial startup and after some period when the
- currently selected unicast source has not been heard. Following the
- defined protocol, the client binds to the first reply heard and
- continues operation in unicast mode. In this mode the local clock can
- be automatically adjusted to compensate for the propagation delay.
-
- In still another scenario suitable for any network and where
- multicast service is not available, the DNS can be set up with a
- common CNAME, like time.domain.net, and a list of address records for
- NTP servers in the same domain. Upon resolving time.domain.net and
- obtaining the list, the client selects a server at random and begins
- operation in unicast mode with that server. Many variations on this
- theme are possible.
-
- 8. Acknowledgements
-
- Jeff Learman was helpful in developing the OSI model for this
- protocol. Ajit Thyagarajan provided valuable suggestions and
- corrections.
-
- 9. References
-
- [COL94] Colella, R., R. Callon, E. Gardner, Y. Rekhter, "Guidelines
- for OSI NSAP allocation in the Internet", RFC 1629, NIST, May 1994.
-
- [DAR81] Postel, J., "Internet Protocol", STD 5, RFC 791,
- USC Information Sciences Institute, September 1981.
-
- [DEE89] Deering, S., "Host extensions for IP multicasting", STD 5,
- RFC 1112, Stanford University, August 1989.
-
- [DEE96] Deering, S., R. Hinden, "Internet Protocol, Version 6 (IPv6)
- Specification", RFC 1883, Xerox and Ipsilon, January 1996.
-
- [DOB91] Dobbins, K, W. Haggerty, C. Shue, "OSI connectionless
- transport services on top of UDP - Version: 1", RFC 1240, Open
- Software Foundation, June 1991.
-
- [EAS95] Eastlake, D., 3rd., and C. Kaufman, "Domain Name System
- Security Extensions", Work in Progress.
-
- [FUR94] Furniss, P., "Octet sequences for upper-layer OSI to support
- basic communications applications", RFC 1698, Consultant,
- October 1994.
-
-
-
-
-
- Mills Informational [Page 17]
-
- RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
-
-
- [HIN96] Hinden, R., and S. Deering, "IP Version 6 addressing
- Architecture", RFC 1884, Ipsilon and Xerox, January 1996.
-
- [ISO86] International Standards 8602 - Information Processing Systems
- - OSI: Connectionless Transport Protocol Specification. International
- Standards Organization, December 1986.
-
- [MIL92] Mills, D., "Network Time Protocol (Version 3) specification,
- implementation and analysis", RFC 1305, University of Delaware,
- March 1992.
-
- [PAR93] Partridge, C., T. Mendez and W. Milliken, "Host anycasting
- service", RFC 1546, Bolt Beranek Newman, November 1993.
-
- [POS80] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
- USC Information Sciences Institute, August 1980.
-
- [POS83] Postel, J., "Time Protocol", STD 26, RFC 868,
- USC Information Sciences Institute, May 1983.
-
- Security Considerations
-
- Security issues are not discussed in this memo.
-
- Author's Address
-
- David L. Mills
- Electrical Engineering Department
- University of Delaware
- Newark, DE 19716
-
- Phone: (302) 831-8247
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Mills Informational [Page 18]
-
-
-
-